The interface that explains itself

Tooltips, onboarding tours, and the little question-mark circle are all the same artefact: a note left at the scene of a design problem, explaining it rather than fixing it.

Where the explanation should live

Most of what ends up in a tooltip belongs in the label. A field called Threshold with a tooltip explaining that it is the number of failures before an alert fires should be a field called Failures before alerting. It is longer. Length is not the cost you think it is.

The rest usually belongs in the structure. If two controls need explaining because their relationship is unclear, the fix is nearly always to put them in the same group with a heading that states the relationship.

The chart that lies quietly

The worst version of this is a chart with a caveat underneath it. A partial day drawn like a complete one, with a footnote saying today is still in progress, is a graph that says collapse and a sentence that says ignore that. The graph wins. It always wins; it is bigger and it arrived first.

Draw the incomplete period differently and the footnote becomes unnecessary, because the picture is now telling the truth on its own.

A useful test

Take every explanatory string on the screen, delete it, and ask what breaks. Whatever breaks is a design problem you had already found and papered over. Whatever nobody misses was never load-bearing.

I have never run this exercise and removed fewer than half of them.